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(57) La presents invention concern e un proced6 de 
paiement, dans une application telematique, de som- 
mes dues par un utiiisateur pour des prestations d£li- 
vrdes par un serveur d'ap plication. 

L'invention concerne 6galement un dispositif de mi- 
se en oeuvre de ce proc6de qui permet I'anonymat. Ce 
dispositif comprend un kiosque (k), au moins un serveur 
d'application (Ai) et au moins un utiiisateur (Uj). Le ser- 
veur d'apptication n'a pas a connaTtre I'identit6 de ('utiii- 
sateur puisque c'est le kiosque qui gere le compte de 
I'utilisateur. De plus le kiosque n'est pas capable de re- 
constituer les transactions effectuees par un tel utiiisa- 
teur aupres de tel serveur d'application, grace a une 
structure particuliere de cheques electroniques. 
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Description 

Domaine technique 

la presente invention concerns un proc6d6 de paie- 
ment dans une application teiematique, et un dispositif 
de mise en oeuvre de ce procede. 

Etat de la technique anteVieure 

Dans une application teiematique, un utilisateurdoit 
payer les prestations que lui deiivre un serveur dupli- 
cation. Des formules d'abonnement indifferencie sont 
trop simpiistes pour etre satisfaisantes a cet egard et ne 
permettent pas de refleter la valeur des informations 
fournies a un utilisateur pour une transaction particulie- 
re. Par ailleurs, I'obligation pour un utilisateur d'avoir a 
faire une demarche d'abonnement aupres de chaque 
serveur consulte ne favorise pas la spontaneity de ses 
consommations. 

L'infrastructure de paiement ne doit cependant pas 
etre trop couteuse, eu egard au faible cout des presta- 
tions g6n6ralement delrvrees. Ceci 6carte des solutions 
ou le serveur facturera it directement son utilisateur (pro- 
cedure de paiement ou teiepaiement classique). Ceci 
explique I'interet des "serveurs de paiement" , ou "kios- 
ques", auxquels les serveurs d'application sous-traitent 
les operations de paiement, puis de recouvrement des 
sommes dues. Ce genre de solutions permet a'un utili- 
sateur de se connecter a un serveur d'application sans 
qu'il ait d'abonnement prealable pour ce serveur, et per- 
met aussi de rendre I'utilisateur anonyme par rapport a 
ce serveur : le serveur d'application n'a plus a avoir d'in- 
formation sur I'identite de I'utilisateur. 

Un exemple de kiosque se rencontre notamment 
pour le Minitel (marque deposee) et les numeros d'appel 
3615 et 3614. Le kiosque fonctionne alors a la duree : 
le kiosque multiplie la duree de la connexion utilisateur/ 
serveur par le taux du palier, et impute la somme ainsi 
obtenue a I'utilisateur 

Pour plus de souplesse, la taxation peut etre definie 
suivant la valeur de reformation foumie par le serveur 
d'application a I'utilisateur. Pour s'assurer de I'accord de 
I'utilisateur, la procedure est alors la suivante : 

le serveur d'application demande a I'utilisateur une 
somme determinee ; 

I'utilisateur, s'il est d'accord, demande au kiosque 
de payer cette somme au serveur d'application ; 
le kiosque debite le compte de I'utilisateur de cette 
somme et cr6dite celui du serveur d'application de 
celle-ci ; 

le kiosque renvoi e un acquittement au serveur d'ap- 
plication, directement ou par I'intermediaire de I'uti- 
lisateur. 

Mais, avec cette approche du paiement, apparait 
un probieme d'anonymat par rapport au kiosque qui, de 
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par ses fonctions, connatt toutes les pratiques et habi- 
tudes des utilisateurs. Meme si le kiosque est exploite 
par une organisation instrtutionneile, un probieme de 
manque d'anonymat, et done d'atteinte a la vie priv6e 

5 de I'individu, se pose alors. 

Un document de Part ant6rieur intitule "Untraceable 
Electronic Cash" de David Chaum, Amos Fiat et Moni 
Naor (Proceedings of Crypto'88, Lectures Notes in 
Computer Science, volume 403, Springer Verlag, pages 

io 319 a 327) concerne une solution de paiement anony- 
me. 

Le principe de ce paiement est alors fe suivant : 

un utilisateur achete de la monnaie elect ronique a 
is sa banque ; 

cet utilisateur depense cette monnaie chez des 
commercants ; 

chaque commercant est collecte par la banque. 

20 Pius pr6cis6ment, ces 6changes peuvent etre d6- 
crits de la facon suivante : le mot "piece" designe une 
donn6e 6mise par la banque, comprenant une signature 
electron ique et ayant une valeur fix6e (1 franc par exem- 
ple). 

25 Pour le chargement : 

1- L'utilisateur demande a la banque une piece de 
1 franc. 

2- La banque d6bite le compte de I'utilisateur de 1 
30 franc ; la banque envoie a I'utilisateur la piece. 

Ces deux etapes peuvent etre repetees plusieurs fois, 
pour avoir plusieurs pieces. 
Pour le paiement on a : 

35 

3- Le commercant demande a I'utilisateur m francs. 

4- L'utilisateur envoie au commercant m pieces. 

5- Le commercant verifie les pieces et stocke cel- 
les-ci. 

40 

Ulterieurement on a la collecte suivante : 

6- le commercant transmet a la banque les pieces 
stockees ; 

45 7- la banque v6rifie les pieces, cumule les montants 
et paye le commercant. 

Pour le paiement, deux cas sont decrits dans ce do- 
cument de I'art anterieur : 
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en "Off- Line" : le commercant et I'utilisateur, lors de 
la transaction ne sont pas en ligne avec la banque. 
Pour expliquer comment le commercant peut s'as- 
surer que la piece eiectronique n'a pas d6ja ete uti- 
55 nsee par l'utilisateur, ou dupliquee par le commer- 
gant, deux methodes sont proposees : 

• une piece est utilisable une seule fois, sous pei- 



EP 0 731 580 A1 



2 



3 



EP 0 731 580 A1 



4 



ne de r6v6!er a la collecte une information per- 
mettant a la banque d'identifier I'utilisateur 
malhonnSte ; ceci est possible grace a une 
structure particuliere des donn6es de la piece 
6lectronique, et ceci implique que la banque 5 
conserve toutes les pieces d6ja collected, 
• pour obtenir une security physique, I'utilisateur 
utilise une carte a puce, objet inviolable, dont 
le comportement ne peut dtre modifid par I'uti- 
lisateur, et qui ne reutilise jamais la meme 10 
piece ; 

en "On-Line" : lors de la transaction entre le com- 
mercant et I'utilisateur, en 5, le commercant contac- 
te la banque pour savoir si la piece prdsentee n'a »s 
pas d£ja ete utilises. La banque doit la aussi con- 
server toutes les pieces d6ja collectees. 

Les transactions ont une valeur inconnue a priori, 
et done la banque donne a I'utiiisateur des pieces d'un 20 
montant pred6termine\ quitte pour I'utilisateur d'en utili- 
ser le nombre qu'il faut pour payer le commercant. Une 
telle procedure est done lourde et pr6sente un probleme 
d'appoint. 

Cette solution pr6sente done de nombreuses diff6- 2s 
rences avec un systeme utilisant un kiosque. 

Dans cette solution, il faut constituer un fichier de 
toutes les pieces collectees, depuis la creation du sys- 
teme de paiement 6lectronique, d'ou une lourdeur tres 
grande. 30 

Une demande de brevet WOA-95/04417 deer it des 
moyens cryptograph iques utilises partrois types de par- 
ticipants dans un systeme Slectronique permettant un 
transfert protege d' informations certifies. Ceci est rea- 
list par un protocole a signature aveugle en combinai- 35 
son avec un protocole de test. Le protocole a signature 
aveugle permet a la partie qui certifie de coder les don- 
n6es en informations certifiers qu'il fournrt a une partie 
qui recoit, de maniere telle qu'elles ne peuvent pas dtre 
alte>6es ou modifiers par cette partie qui recoit. Le pro- *o 
tocole de test permet aux parties de prouver differentes 
caracterist iques concemant les donnees cod6es dans 
leurs informations certifiees. 

Cette demande de brevet rappelle I'etat de I'art con- 
nu, notamment le concept de signature aveugle du a 45 
Chaum prot6ge par le brevet US-A-4 759 063. Celui-ci 
permet d'obtenir et d'utiliser une information signee par 
une autoritd, cette information 6tant connue de I'utilisa- 
teur qui la demande, mais pas de l'autorite\ Si cette in- 
formation repr6sente une piece 6lectronique, elle doit so 
§tre utilised seulement une fois. Rien ne peut empScher 
de dupliquer des donn6es informatiques ; il faut done 
que la ^utilisation d'une piece Slectronique ddja utilised 
permette de revdler I'identite de I'utilisateur qui a frauds. 
Un protocole permettant de signer de facon aveugle une ss 
information doit done contenir de quoi reperer I'utilisa- 
teur s'il fraude. Cette information, si elle contient bien 
de quoi reperer I'utilisateur a qui elle est donnee, est 



souvent dite "bien form6e" dans l'6tat de I'art. Or "aveu- 
glement" et "bien form6e" sont antinomiques a priori. 
Une melhode dite "cut and choose" permet de resoudre 
cette apparente contradiction : ne pas connaitre une in- 
formation tout en etant sOr qu'elle possede une certaine 
propri6te\ 

Dans ladite demande de brevet est 6nonc6 un "res- 
trictive blind signature scheme" plus performant que la 
methode "cut and choose" d6finie plus haut. L'informa- 
tion sign6e, appel6e "credential" est constitute de facon 
a n'etre utilisable qu'une fois. Cette information signee 
peut aussi etre combined avec une quantity telle que le 
montant. Tout ceci est applicable a un systeme de paie- 
ment "off-line" de type piece ou cheque electronique. 

Dans ie cas d'un paiement par pieces ou cheques, 
on a alors trois acteurs : la banque B, I'utilisateur U, le 
commercant (shop) S. U peut payer par exemple un 
journal chez un commercant S, mais U peut aussi payer 
un foumisseur d'informations S qu'il consulte avec son 
PC sur INTERNET. 

Dans le cas de pieces 6lectroniques, il s'agit d'une 
transcription dlectronique des pieces ou billets utilises 
dans la vie de tous les jours. Les echanges entres ces 
diff 6 rentes parties sont les suivants : 

• Rechargement de U (son PC, ou sa carte) avec des 
pieces qu'il stocke en m6moire : cette procedure se 
passe entre U et B. Ces pieces ont une valeur fig6e, 
par exemple 1$. Le protocole permet de charger 
une telle piece, avec la propri6te, expliquee plus 
haut, d'anonymat (signature aveugle), et de verifier 
qu'elles sont bien formers : elles contiennent I'iden- 
tite de U. La banque doit bien sur connaTtre cette 
identification pour deb iter le compte de U du mon- 
tant de pieces achetSes par U. 

• Paiement par U d'un commercant S : une fois que 
U possede des pieces, il peut les utiliser pour des 
achats. Le protocole est done une preuve de con- 
naissance non reutilisable que U a dans sa m6moi- 
re les donnees relatives a une piece 1$. Le paie- 
ment est totalement dSconnecte* du rechargement, 
qui doit avoir £t§ fait avant, pour que U dispose du 
montant de pieces ntcessaires. Cette procedure ne 
fait intervenir que U et S. 

• . Remise de S a B : S a done accumule des pieces 
(ou plutot des preuves de connaissance de pieces) 
qui lui ont 6t6 donn6es par ses clients. Au moyen 
d'un protocole (non d6taille* dans WO-A-95/04417), 
il vide les pieces accumul6es pour que B erudite son 
compte d'un montant correspondant. La banque 
doit proctder a des contrdles de non r6utilisation 
(dgalement non ddtaillds). Si elle retrouve pour la 
m§me piece plusieurs utilisations (preuves de con- 
naissance), alors un traitement simple permet de 
retrouver I'identite" de U qui avait achet£ et defense 
ces pieces. 

Dans le cas de cheques dlectroniques, il s'agrt 
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d'une approche tegerement diff6rente de celle des pie- 
ces electron iques. Mais elle utilise des protocoles tres 
voisins. Elle est d'un emploi plus simple. En effet, les 
pieces ont une valeur fixe (1 $ par exemple). Pour payer 
par exemple 9$, il faut utiliser neuf pieces. Avec les che- 
ques, le montant est defini lors de I'utilisation de la piece. 
Dans I'exemple defini ci-dessus U fera done un seul 
cheque de 9$. 

• U achete un cheque d'un montant maximum M. Ce 
montant M est ins6r6 dans les informations repre- 
sentant le cheque (analogue au cas des pieces). Le 
protocole permet de faire ce chargement de facon 
tres voisine au cas d'une piece de montant M. M est 
soustrait du compte de U. 

• U utilise pour payer un montant m, demande par S, 
un cheque de montant maximum M £ m. Le proto- 
cole est tres proche du paiement avec une piece, 
mais la preuve de connaissance comporte de plus 
le parametre m. 

• Remise par S des cheques recus (ou plutet des 
preuves de connaissance de ces cheques) a B: 
processus analogue au cas des pieces. 

• Un 6change supp!6mentaire doit avoir lieu entre U 
et B, pour que U se fasse rembourser sur son comp- 
te la difference M-m. 

Cette demande de brevet WO-A-95/04417 decrit 
aussi I'utilisation de modules "tamper resistant", ce qui 
permet de garantir que U ne pourra utiliser deux fois le 
meme cheque ou la meme piece, de par la constitution 
de la machine (carte a puce ou PC) contenant ces pie- 
ces ou cheques, ainsi que la creation de compte ano- 
nyme, qui consiste a convenir d'un pseudonyme entre 
U et B (U ne devoiiant pas son identite a B). 

Par contre la pnSsente invention a pour objet un pro- 
cede d'echanges entre un utilisateur, un kiosque et un 
serveur d'application, resolvant le probleme d'anony- 
mat. Cet anonymat est relatif au kiosque et non aux re- 
seaux (il peut y en avoir plusieurs) qui se trouvent entre 
les utilisateurs et les serveurs. Ces r£seaux sont appe- 
les a connattre les adresses reseau de ces diff^rents 
acteurs. Ces adresses peuvent d'ailleurs varier: e'est 
par exemple (e cas d'un utilisateur qui se deplace. 

Expos6 de Pinvention 

La prdsente invention concerne tin proc6d6 de 
paiement, dans une application tel6matique, de som- 
mes dues par un utilisateur pour des prestations deli- 
vr6es par un serveur d'application, caract6ris6 en ce 
qu'il comprend les etapes suivantes : 

ledrt serveur d'application envoie audit utilisateur 
une demande de paiement pour une somme 
determined ; 

ledrt utilisateur demande a un serveur de paiement, 
ou kiosque, donne le paiement de ladite somme 



determinee ; 

ledit serveur de paiement debite le compte dudit uti- 
lisateur de ladite somme determinee, et envoie 
audit utilisateur un cheque 6lectronique correspon- 
5 dant a la somme determinee ; 

ledit utilisateur vSrifie ce cheque electronique, le 
modifie pour que le serveur de paiement ne le re- 
connaisse pas, et I'envoie audit serveur 
d'application ; 

w - ledit serveur d'application v6rifie ce cheque electro- 
nique et stocke celui-ci ; 

et en ce que, dans des Stapes urterieures : 

is - ledit serveur d'application transmet audit serveur de 
paiement au moins un cheque electronique stocke ; 
ledit serveur de paiement verifie chacun des che- 
ques 6lectroniques recus et paye audit serveur 
d'application le montant cumule de ceux-ci. 

Dans le contexte technique des reseaux tele>nati- 
ques et serveurs de paiement ou kiosques, le procede 
de invention concerne une organisation de la fonction 
paiement basee sur des "cheques 6lectroniques" dont 
la constitution de principe est definie. Cette approche 
permet un anonymat complet des actions de ('utilisateur. 

Un "cheque" designe un ensemble de donnees 
electroniques Smises par un serveur de paiement. II 
comprend une signature electronique et a une valeur 
determinee. Avantageusement un cheque contient une 
information concernant son montant et sa date, ainsi 
qu'un alea. 

Avantageusement la verification de la septieme 
I'etape concerne la signature des cheques, la non-pre- 
sence d'un cheque identique dans le fichier des che- 
ques recus et la mise a jour de ce fichier avec ce nou- 
veau cheque. 

Avantageusement, maigre les traitements preala- 
bles, les cheques recus apres i'6tape de transmission 
d'au moins un cheque electronique, stocke par le ser- 
veur d'application, au serveur de paiement ne peuvent 
etre correles avec ceux envoy 6s dans i'etape d'envoi 
d'un cheque electronique par le serveur de paiement a 
('utilisateur, grace a la modification de I'etape d'envoi du 
cheque au serveur d'application, ce qui permet de gar- 
der Panonymat de ('utilisateur. 

Les serveurs d'application peuvent collector leurs 
cheques avec une certaine p6riodicite\ par exemple in- 
ferieure a la semaine. 

Dans une premiere variante le precede de I'inven- 
tion permet de resoudre les litiges gventueis entre paie- 
ment et remise de Pinfonmation 6lectronique, selon deux 
moyens, et ceci bien que Panonymat soit une caracte- 
ristique importante d'un tel proc6de : 

L'information envoy6e par le serveur d'application 
a Putilisateur peut etre chiffrde. La cle de d6chiffre- 
ment est calculee par le kiosque lors du d£bit du 
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compte de i'utilisateur et envoyee a i'utilisateur. Le 
serveur d'application signe ce qu'il envoie a I'utili- 
sateur, ainsi paiement et remise sont synchronises. 
Ainsi le serveur d'application ne peut plus rSpudier 
son envoi a I'utilisateur pour etre paye par lui sans 5 
lui fournir de service, c'est-a-dire sans lui envoyer 
une information utiiisable. II protege rintegrite de ce 
qu'il envoie (pour eviter que I'utilisateur n'aitere Tin- 
formation dans I'intention de se faire rembourser). 
Le kiosque est le "juge" qui, en cas de Irtige, dispose io 
des elements cryptographiques irrefutables lui per- 
mettant de savoir qui est le fautif. 
La remise par le serveur d'application des informa- 
tions a I'utilisateur se fait apres reception du cheque 
de I'utilisateur, mais le serveur s'engage avant le is 
paiement sur la remise de Pinformation par une si- 
gnature Slectronique. Ceci rSsout tous les cas de 
fraude de I'utilisateur. Le serveur d'application ne 
s'engage sur I'information qu'il va fournir a I'utilisa- 
teur, qu'apres le paiement, par une signature. 20 

Contrairement au systeme dScrit le document de 
I'art antSrieur cits plus haut, dans cette approche kios- 
que le chargement et le paiement sont lies, car ils se 
font en mfirne temps : I'utilisateur, le serveur d'applica- 25 
tion et le kiosque sont "On-Line". Ceci simplifie le pro- 
bleme de la verification de la non duplication des pieces 
par I'utilisateur : un alea choisi par le serveur d'applica- 
tion empeche I'utilisateur de rSutiliser des donnees de 
signature du serveur d'application qu'il aurait obtenu 30 
auparavant. L'utilisateur connait le montant demands 
par le serveur d'application ; il n'y a plus de problemes 
d'appoint. 

Le probleme de duplication par le serveur d'appli- 
cation de cheques se resout en rajoutant au montant, 35 
un horodatage, controls par le kiosque tors de la tran- 
saction., Comme les pieces sont consommSes juste 
apres avoir ete achetSes par I'utilisateur du kiosque, 
alors il sufflt pour le kiosque de tester les doublons sur 
une periode egale au temps separant deux collectes. 40 

L'invention conceme Sgalement un dispositif de mi- 
se en oeuvre de ce procSdS, dans iequel au moins un 
kiosque, au moins un serveur d'application sont en 
liaison avec au moins un utilisateur par I'intermediaire 
d'un reseau de communication. Les techniques de si- 45 
gnature aveugle permettent de laisser apparents dans 
les informations signees le montant et la date, et ame- 
nent une simplification importante par rapport aux tech- 
niques habituelles. 

so 

Breve description des dessins 

Les figures 1 a 3 iliustrent le procSdS de l'invention ; 
les figures 4 et 5 iliustrent deux procSdSs de I'art 
antSrieur ; ss 
les figures 6 et 7 iliustrent respect ivement deux va- 
riantes du procSdS de l'invention. 



ExposS detaille de modes de realisation 

Le dispositif de mise en oeuvre du procSdS de l'in- 
vention, tel que represents sur la figure 1 comprend un 
kiosque K, des serveurs d'application A1 a Am, et des 
utifisateurs U1 a Un tous relies a un reseau de commu- 
nication. 

Ledit procSdS est un procSdS de paiement dans une 
application tSISmatique, dans Iequel Tanonymat de I'uti- 
lisateur vis-a-vis du kiosque est respects. 

Si on dSsigne par U un des utilisateurs, A un des 
serveurs d'application et K le kiosque, on peut dSfinir 
I'anonymat par deux regies : 

regie 1 : le serveur d'application A ne doit pas con- 
naitre I'utilisateur U ; 

regie 2 : le kiosque K ne doit pas savoir que I'utili- 
sateur U utilise (ou a utilisS) le serveur A. 

Mais ceci ne doit pas empecher le serveur d'appli- 
cation d'Stre payS pour les prestations qu'il effectue pour 
i'utilisateur. La regie 1 n'a bien sur pas de sens si rap- 
plication serveur requiert I'identitS de I'utilisateur et si 
I'utilisateurfoumit cette identitS. Mais dans le cas le plus 
gSnSral, la regie 1 doit s'appliquer. La regie 2 permet de 
protSger la vie privSe des clients. Elle doit dtre entendue 
au sens que le kiosque ne doit avoir aucune possibilitS 
pour reconstituer les identifiants des applications sSlec- 
tionnSes par les utilisateurs. 

On considere que I'utilisateur utilise un moyen de 
paiement non anonyme car, dans le cas contraire, I'ano- 
nymat des transactions utilisateur/serveur/kiosque est 
inhSrent au systeme de paiement utilisS. 

Les cas couverts par l'invention sont done : 

le paiement par carte bancaire ou carte 
d'abonnement ; 

le simple abonnement : I'utilisateur n'a, pour acce- 
der au kiosque, qu'un mot de passe qui lui a ete 
donnS lors de son abonnement au kiosque. 

Lors d'une transaction, le kiosque va done connaT- 
tre I'utilisateur et son identitS idU, c'est-a-dire son nu- 
mSro de carte bancaire ou son numSro d'abonne a I'ope- 
rateur du kiosque. 

II existe alors diffSrents cas de raccordements : 

un premier cas se prSsente lorsque la fonction pas- 
se relle utitisateurs/serveurs (concentration, adap- 
tation des transmissions et protocoles) est confon- 
due avec la fonction kiosque. Ce cas peut Stre 
schSmatisS : 

U-K-A 

Dans ce cas, la regie 2 ne peut Stre satisfaite, puis- 
que le kiosque K doit Stablir la connexion avec le 
serveur d'application A, done connait re son 
identitS ; 
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dans un second cas schematise : 
U - A-K 

Le serveur d'application doit etablir la connexion 
avec le kiosque, et si ceci n'implique pas que le kios- 5 
que connaisse le serveur d'application, alors cette 
solution de raccordement n'est pas incompatible 
avec la regie 2. De meme la regie 1 peut etre satis- 
faite, mais comme le serveur d'application se trouve 
entre I'utilisateur et le kiosque, il faut que les don- 10 
riees d'identite de I'utilisateur (idU) soient chiffrees 
entre I'utilisateur et le kiosque ; 
un troisieme cas peut etre schematise : 

A 15 



U 




20 



A l'6vidence, cette solution est compatible avec les 
regies 1 et 2. Cette solution n'implique pas deux li- 25 
gnes de transmission differentes issues de I'utilisa- 
teur. Une meme liaison physique peut contenir plu- - 
sieurs canaux, chacun avec des destinataires diffe- 
rents. De nombreux reseaux, avec les protocoles 
de transport adequats, offrent ces possibilites : 30 
Transpac (marque depos6e), Itineris (marque de- 
posee) en France.... 

Dans la suite de la description on se place, a titre 
d'exemple, dans cette derniere hypothese de raccorde- 35 
ment. Le second cas conviendrait aussi, moyennant de 
respecter les conditions correspondantes. 

Comme represents sur ia figure 2 les echanges se- 
Ion le procede de I'invention peuvent etre decrits par la 
succession des etapes suivantes : 40 

1 - Le serveur A envoie a I'utilisateur U une demande 
pour une certaine somme (bloc 11). 

2- L'utilisateur U demande au kiosque K cette som- 
me (bloc 12). 45 

3- Le kiosque K debite le compte de I'utilisateur U 
de cette somme : le kiosque K envoie a I'utilisateur 
U un cheque eiectronique de cette somme (bloc 
13). 

4- L'utilisateur U ve>ifie ce cheque, le modifie pour 50 
que le serveur de paiement ne le reconnaisse pas 

et I'envoie au serveur d'application A (bloc 14). 

5- Le serveur A v6rifie et stocke ce cheque (bloc 
15). 

55 

Ulterieurement (test 18) : 

6- Le serveur d'application A transmet au kiosque 



K les cheques stockes (bloc 16). 

7- Le kiosque K verifie les cheques, cumule les 

montants et paye ie serveur A (bloc 17). 

Le mot "cheque eiectronique", par analogie avec un 
cheque classique, designe un ensemble de donnees 
electroniques ou numSriques emises par le kiosque, 
comprenant notamment une signature electron ique, et 
ayant une valeur convenue. II constitue pour le serveur 
d'application une garantie de paiement. Le serveur A 
stocke celui-ci et presente au kiosque K, ulterieurement, 
pour etre paye a son tour. 

Le cheque est une signature par le kiosque du mon- 
tant m. Pour des problemes de rejeux il contient aussi 
un alea c qui est choisi par le serveur d'application et 
envoye a I'utilisateur dans I'etape 1. 

Si, dans les echanges represent6s a la figure 2, on 
utilise un alea c, un probleme d'anonymat se pose Car 
il devient possible au kiosque de relier, grace a cet alea 
c, I'echange de I'etape 2 entre Putilisateur et le kiosque, 
et I'echange de I'etape 6 avec un cheque de meme mon- 
tant m et de meme alea. La regie 2 ne peut done plus 
etre satisfaite. En fait, I'information gdnante pour I'ano- 
nymat est I'alea c : le montant m peut permettre de relier 
les etapes 2 et6, mais en pratique, I'utilisateur peut frac- 
tionner son paiement en valeurs 6l6mentaires (comme 
quand on paye avec des pieces ou billets). Done le mon- 
tant m va correspondre a des montants predefinis, et de 
nombreuses transactions auront le meme m. par exem- 
ple pour payer 11 francs, l'utilisateur peut demanderau 
kiosque un cheque de 10 francs et un de 1 franc. 

Pour rSsoudre ce probleme, I'invention utilise done 
un mecanisme de signature aveugle, dont le principe 
est decrit dans I'article intitule "Blind Signatures for Un- 
traceable Payments" de David Chaum (Crypto'82, Ple- 
num Press, New- York, 1983, pages 199 a 203). Le me- 
canisme de I'invention peut §tre represents par le sche- 
ma illustre a la figure 3. Le montant m contient une in- 
formation sur le montant du cheque, et la date : cette 
derniere information permet au kiosque d'eViter des re- 
jeux par le serveur d'application de cheques deja 
utilises : le kiosque n'a pas a memoriser tous les che- 
ques deja utilises, mais simplement, par exemple, ceux 
de la semaine courante, si les serveurs d'application 
collectent leurs cheques par exemple, avec une perio- 
dicite inferieure a ia semaine. Dans I'etape 7, la verifi- 
cation conceme done la signature Sig des cheques, la 
non presence d'un cheque identique dans le fichier des 
cheques recus la semaine, et la mise a jour de ce fichier. 

Plusieurs exemples de signatures aveugles ont ete 
developpes dans I'art anterieur. 

Un systeme dit RSA decrit notamment dans un ar- 
ticle intitule "A Method for Obtaining Digital Signatures 
and Public-Key Cryptosystems" (Communications of 
the ACM, fSvrier 1 978, pages 1 20 a 1 26) et dans 'L'echo 
des recherches" n° 124, 2 6 " 16 trimestre 1986, page 39, 
est un exemple type de systeme a cle publique. 

Les sch6mas de signature aveugle avec RSA sont 
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classiques. Les calculs se font dans Zn (entiers modulo 
n). c est calcule par c = P(r).c\ ou r est un alea preala- 
blement choisi par le demandeur de la signature de I'uti- 
lisateur. P est la fonction publique inverse de Sig. 
D'apres les propriety multiplicatives de RSA, Sig(c) = s 
r.Sig(c') et done Sig(c').= Sig(c)/r. 

Mats dans ce schema, il n'est pas possible de com- 
biner une, partie aveugle c et une partie m qui ne Test 
pas. 

Les adaptations au schema general ci-dessus sont 10 
done : 

pour le montant : avoir des cles RSA differentes 
pour differentes valeurs de cheques : par exemple 
franc, 5 francs, 10 francs... ; is 
pour la date : le kiosque change period iquement 
ces cles : toutes les semaines dans Texemple ci- 
dessus. 

Un article intitule "Efficient Identification and Signa- 20 
tures for Smart Cards" de CP. Schnorr (Proceedings of 
Crypto'89, Lectures Notes in Computer Science, volu- 
me 435, Springer Verlag, pages 239 a 252) decrit un 
systeme de signature. 

On considere les notations suivantes : 25 

n nombre premier (5 1 2 bits) ; b, , b 2 element de Zn*, 
d'ordre q, grand ; 

s secret du kiosque, appartenant a Zn* ; 
p v p 2 cles publiques du kiosque : p.,= b 1 8 2.,= b 2 6 ; 30 
h fonction de condensation, publique, a resultat 
dans Zq. Tous les calculs d'exponentiation sont faits 
modulo n ; les calculs de y, c, y', c' sont faits modulo 

q- 

35 

Comme represents sur la figure 4 on peut utiliser le 
schema de Schnorr avec un generateur b dependant de 
m : b = m b 2 . Ce choix permet d'eviter certaines fai- 
blesses d'un choix plus simple b = b t m du fart que bP = 
( b, m b 2 )P et trouver m* et p' tel que (b, m 'b 2 )p' = bP est *o 
d'une difficult^ identique au probleme du logarithme 
dans Zn. 

Pour effect uer la verification on effectue les calculs 
de b = b, m b 2 ; p = p n m p 2 ; c' = h(a,t', idA) ; le test bv' = 
t'p c ". 45 

Un article intitule "A Practical Zero-Knowledge Pro- 
tocol Fitted to Security Microprocessor Minimizing Both 
Transmission and Memory" de L.C. Guillou et J.J. Quis- 
quater ("Proceedings Eurocrypt' 88, Springer Verlag, 
Lecture Notes in Computer Sciences" volume 330 - so 
1988 - pages 123-128) decrit un schema dit GQ base 
sur la difficulty de factoriser de grands entiers. 

On prend les hypotheses et notations classiques du 
schema GQ : 

55 

n : grand nombre, produrt de deux nombres pre- 
miers p et q. 

e : nombre premier entier (le calcul dans Zn des ra- 



cines e-iemes est possible si Ton connait p et q). 
g : est une fonction de Hashing, publique, a resultat 
dans Zn ; elle doit, pour eviter certaines possibilites 
d'attaque, etre telle que h(a) h(b) # h(a;b), h etant 
une fonction de Hashing publique, a resultat dans 
Ze. 

E : mentionnee plus bas, est ia fonction "partie en- 
tiere". 

r = E(c'+u/e) vaut done 0 ou 1 . 

Tous les calculs avec des exponentiations sont faits 
modulo n. 

Comme represents sur la figure 5, on peut utiliser 
le schema GQ avec valeur d'authentification v = (g 
(m)) 1 '°. 

La verification du cheque (y\ t\ a, m) se fait par : 
calcul de I = g(m) ; c' = h(a, t', idA) ; verification que y' e 
= t'K 

Par contre, le probleme resolu dans le procedS de 
Tinvention concerne la remise d'informations I que I'uti- 
lisateur achete au serveur d'application. Dans une tran- 
saction tSlematique, ou les relations entre partenaires 
sont depersonnalisees (rendues anonymes grace aux 
protocoles prec6demment decrits), et effect uees par 
des machines dont le comportement peut a priori etre 
modifie, il faut s'assurer que la malversation qui consiste 
pour I'utilisateur a ne pas payer la prestation que lui a 
d6livre un serveur d'application, ou pour un serveur 
d'application a ne pas delivrer la prestation pour laquelle 
I'utilisateur I'a paye, n'est pas possible. 

Deux variantes de Tinvention sont proposees : la 
premiere variante est la plus "naturelle", et necessite les 
memes echanges que d6crit precedemment, au vu de 
la figure 3 ; la deuxieme variante separe les echanges 
concernant le paiement et la remise d'informations. 

On utilise aiors les notations suivantes : 

Sk/Pk, Sa/Pa : cles secretes et publiques du kios- 
que et du serveur d'application ; les cles publiques 
sont connues de tous, ce qui permet les verifica- 
tions de signatures ; 

I : information servie par le serveur d'application a 

I'utilisateur ; 

I' : I chiffre par r ; 

r : cle de chiffrement ; et 

f : c!6 de chiffrement chiffree par Pk : r* = Pk(r). 

Dans la premiere variante. illustr6e a la figure 6, Tin- 
formation I envoy6e par un serveur d'application a un 
utilisateur est chiffree et done inexploitable tant que I'uti- 
lisateur n'a pas la cle. La cle de dechiffrement est cal- 
culee par le kiosque lors du debit du compte de i'utilisa- 
teur, et renvoyee a I'utilisateur. Le serveur d'application 
signe ce qu'il envoie a I'utilisateur de facon a ne pouvoir 
repudier son envoi (pour etre paye par I'utilisateur sans 
lui fournir de service, e'est-a-dire sans lui envoyer une 
information I utilisabie), et a proteger I'integrit6 de ce 
qu'il envoie (pour dvrter que I'utilisateur n'altere Tinfor- 
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mation I dans I'intention de se fairs rembourser). Le 
kiosque est le "juge" qui en cas de litige, dispose des 
elements cryptographlques irrefutables lui permettant 
de savoir qui est le fautif. 

On peut alors considerer plusieurs scenarios de s 
fraudes. 

Si le serveur d'application ne veut pas servir 
I'utilisateur : 

le serveur d'application triche sur sa signature : Puti- 10 
lisateur peut verifier Sa(l\ r\ c',m). Si la verification 
est negative, ta transaction doit etre arretee ; 
le serveur d'application friche sur le contenu de I'in- 
formation I envoyee : Sa (l\ r\ c', m) authentifie les 
informations l\ r\ c\ m ; I'utilisateur peut se retour- is 
ner vers le kiosque qui, avec r, est convaincu que 
I'information renvoyee par le serveur d'application 
est inutilisable. 

Si I'utilisateur ne veut pas payer le serveur 20 
d'application : 

I'utilisateur peut changer le montant demande au 
kiosque. II demande ml au lieu de m, m1<m: le 
serveur d'application peut s'en apercevoir et se 2s 
plaindre au kiosque ; avec r\ le kiosque retrouve 
I'identite de I'utilisateur (idU) ; et I'utilisateur ne peut 
montrer au kiosque une signature Sa(l\r\c , i m1) 
puisqu'il a recu Sa(r,r , ,c , m) ; 

I'utilisateur peut ne pas demander ce cheque au 30 
kiosque : il n'a pas r qui lui permet de transformer P 
en I ; 

I'utilisateur peut ne pas renvoyer sig(m,c'), au ser- 
veur d'application. Mais le .compte de I'utilisateur a 
deja et6 dSbite de m. Done ce n'est pas une fraude 35 
intSressante pour I'utilisateur. Le serveur d'applica- 
tion connaTt c*. r* et r ; il se plaint aupres du kiosque 
qui, avec r' retrouve I'identite de I'utilisateur (idU), 
et c. Le kiosque retrouve done tout ce qu'il avait ren- 
voye a I'utilisateur ; i'utilisateur est done confondu. 40 

Si le serveur d'application rSpudie le paiement 
recu : 

le serveur d'application doit apporter comme preu- 45 
ve au kiosque : c' et r*. Avec r*. si le kiosque retrouve 
IdU, I'utilisateur a bien paye le serveur d'application. 
Si le kiosque ne retrouve pas IdU, les preuves ap- 
portees par le serveur d'application sont fausses. 

50 

L'anonymat obtenu dans le cas de cette variante est 
conditionne au fait qu'il n'y ait pas collusion entre le ser- 
veur d'application et le kiosque pour retrouver i'utilisa- 
teur. Cette hypothese est necessaire pour pouvoir traiter 
les cas de fraudes decrits ci-dessus. ss 

Si I'on considere alors la seconde variante, illustree 
a la figure 7 : la remise par le serveur d'application d'in- 
formations I a I'utilisateur se fait apres reception du che- 



que de I'utilisateur ; ceci resout tous les cas de fraudes 
de I'utilisateur. Le serveur d'application s'engage sur I'in- 
formation qu'il va fournir a I'utilisateur apres le paiement, 
par une signature Sa(l,c',m). 

Si le serveur d'application triche (incoherence entre 
la signature Sa donnSe et I recu, ou non remise par le 
serveur d'application de I) I'utilisateur peut se retourner 
vers I e kiosque en donnant comme elements de preuve 
de sa bonne foi le cheque m, c\ c et Sa(l,m,c'). 

Si I'utilisateur triche, il n'y a pas de risques pour le 
serveur d'application car il ne delivre I qu'apres verifica- 
tion du paiement. 



Revendications 

1 . ProcecJe de paiement, dans une application telema- 
tique, de sommes dues par un utilisateur pour des 
prestations delivrSes par un serveur d'application, 
caracterisS en ce qu'il comprend les Stapes 
suivantes : 

ledit serveur d'application envoie audit utilisa- 
teur une demande de paiement pour une som- 
me dSterminSe (11) ; 

ledit utilisateur demande a un serveur de paie^ 
ment, ou kiosque, donne le paiement de ladite 
somme dSterminSe (12) ; 
ledit serveur de paiement debite le compte du- 
dit utilisateur de ladite somme determinee, et 
envoie audit utilisateur un cheque Slectronique 
correspondant a la somme determinee (13) ; 
ledit utilisateur vSrifie ce cheque electronique, 
le modifie pour que le serveur de paiement ne 
le reconnaisse pas, et I'envoie audit serveur 
d'application (14) ; 

ledit serveur d'application verifie ce cheque 
electronique et stocke celui-ci (15) ; et en ce 
que, dans des Stapes ulterieures : 
ledit serveur d'application transmet audit ser- 
veur de paiement au moins un cheque electro- 
nique stocks (16) ; 

ledit serveur de paiement vSrifie chacun des 
cheques electroniques recus et paye audit ser- 
veur d'application le montant cumule de ceux- 
ci (17). 

2. Precede selon la revendication 1 , caracterisS en ce 
qu'un cheque designe un ensemble de donnees 
electroniques emises par le kiosque, comprend une 
signature Slectronique et a une valeur dSterminee. 

3. ProcSdS selon la revendication 2, caracterisS en ce 
qu'un cheque contient une information concemant 
son montant, sa date, ainsi qu'un alea. 

4. ProcSdS selon la revendication 1 , caracterisS en ce 
que la verification de la septieme Stape (17) con- 
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cerne la signature des cheques, la non-presence 
d'un cheque identique dans le fichier des cheques 
recus et la mise a jour de ce fichier. 

Precede selon la revendication 1 , caracterise en ce s 
que, malgre les traitements prealables, les cheques 
recus apres I'etape de transmission d'au moins un 
cheque electronique, stocke par le serveur d'appli- 
cation, au serveur de paiement ne peuvent etre cor- 
reles avec ceux envoyes dans I'etape d'envoi d'un 10 
cheque electronique par (e serveur de paiement a 
I'utilisateur, grace a la modification de I'etape d'en- 
voi du cheque au serveur d'application, ce qui per- 
met de garder I'anonymat de I'utilisateur. 

15 

Precede selon la revendication 1 , caracterise en ce 
que les serveurs d'application collectent leurs che- 
ques avec une certaine periodicite. 

Precede selon I'une quelconque des revendications 20 
precedentes, caracterise en ce qu'il permet de re- 
soudre les litiges eventuels entre paiement et remi- 
se de I'information electronique, selon deux 
moyens, et ceci bien que I'anonymat soit une ca- 
racteristique importante d'un tel precede : 2s 

I'information envoy6e par le serveur d'applica- 
tion (A) a I'utilisateur (U) peut etre chiffree, la 
cle de dechiff rement est calculee par le kiosque 
(K) lors du debit du compte de I'utilisateur (U) 30 
et renvoyee a I'utilisateur (U), et le serveurd'ap- 
plication (A) signe ce qu'il envoie a I'utilisateur 
(U), ainsi paiement et remise sont 
synchronises ; 

la remise par le serveur d'application (A) des 35 
informations (I) a I'utilisateur (U) se fait apres 
reception du cheque de I'utilisateur (U), mais le 
serveur s'engageant avant le paiement sur la 
remise de I'information, par une signature elec- 
tronique. 40 

Dispositif de mise en oeuvre du precede selon I'une 
quelconque des revendications 1 a 7, caracterise 
en ce qu'ii comprend au moins un kiosque (K), au 
moins un serveur d'application (A) en liaison avec 45 
au moins un utilisateur (U) par ('intermediate d'un 
reseau de communication, les techniques de signa- 
ture aveugle permettant de laisser apparentes dans 
les informations signees le montarit et la date, et 
amenant une simplification importante par rapport so 
aux techniques habituelles. 
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LE SERVEUR D'APPLICATION ENVOIE 
A L'UTILISATEUR UNE DEMANDE DE PAIEMENT 
POUR UNE SOMME DETERMINEE 



L'UTILISATEUR DEMANDE A UN 
SERVEUR DE PAIEMENT DONNE LE PAIEMENT 
DE LADITE SOMME DETERMINEE 



LE SERVEUR DE PAIEMENT DEBITE LE COMPTE DUDIT 
UTILISATEUR DE LADITE SOMME DETERMINEE. ET 
LUI ENVOIE UN CHEQUE ELECTRONIQUE 
CORRESPONDANT A LA SOMME DETERMINEE 



L'UTILISATEUR VERIFIE CE CHEQUE ELECTRONIQUE 
ET L'ENVOIE AU SERVEUR D'APPLICATION 



LE SERVEUR D'APPLICATION VERIFIE CE CHEQUE 
ELECTRONIQUE ET STOCKE CELUI-CI 



NON 




OUI 



LE SERVEUR D'APPLICATION TRANSMET 
AU SERVEUR DE PAIEMENT AU MOINS UN 
CHEQUE ELECTRONIQUE STOCKE 



LE SERVEUR DE PAIEMENT VERIFIE CHACUN OES 
CHEQUES ELECTRONIQUES RECUS 
£T PA YE AUDIT SERVEUR D'APPLICATION LE 
MONTANT CUMULE DE CEUX-CI 
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